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in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
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Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3 GPP and ETSI identities can be found under 
http://webapp.etsi.org/key/queryform. asp . 
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Foreword 



This Technical Specification (TS) was produced by ETSI Technical Committee Telecommunications and Internet 

converged Services and Protocols for Advanced Networking (TISPAN) and originally published as 

ETSI TS 182 006 [ii]. It was transferred to the 3 rd Generation Partnership Project (3GPP) in December 2007. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

x the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 

Introduction 

This clause is optional. If it exists, it is always the second unnumbered clause. 
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Scope 



The present document provides the ETSI endorsement of the 3GPP TS 23.228 "IP Multimedia Subsystem; Stage 2, 
Release 7". 

The present document provides the necessary adaptions to the 3GPP IP Multimedia Core Network Subsystem (IMS), in 
order to support the Access Networks and terminals in the scope of the present NGN Release. The present document 
also includes certain elements from 3GPP Release 8 (TS 23.228 v8.2.0) 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 23.228: "3rd Generation Partnership Project; Technical Specification Group Services 

and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 7)". 

[ii] ETSI TS 182 006 v2.0.3: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description [3GPP TS 
23.228 Release 7, modified]". 



Endorsement notice 

The elements of 3GPP TS 23.228 [1] apply, with the following modifications. 

NOTE: Underlining and/or strike-out are used to highlight detailed modifications where necessary. 

3 Global modifications to 3GPP TS 23.228 

3GPP TS 23.228 [1] was originally written specifically with mobile terminals in mind accessing the IMS using GPRS. 
Unless otherwise specified in the present document, requirements indicating mobile terminals should be taken as also 
being applicable to all terminals accessing the NGN. 

Additionally replace items in 3GPP TS 23.228 [1] as follows: 

• "HSS" with"UPSF". 

• "IM CN Subsystem" with "IMS Core". 

NOTE: Those changes are assumed globally for the present document. 

Clause 2 "References" 

Insert the following references at the end of clause 2: 

[57] IETF RFC 4769 (November 2006): "IANA Registration for an Enumservice Containing Public 

Switched Telephone Network (PSTN) Signaling Information". 
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Editor's note: The gap in the references number series is intentional, to avoid reference number collisions with reference 
number that 3 GPP may allocate in the future. 



[96] 
[97] 
[98] 
[99] 



IETF RFC 3022: "Traditional IP Network Address Translator (Traditional NAT)". 

ETSI ES 282 003: "TISPAN NGN; Resource and Admission Control Subsystem (RACS)". 

ETSI TS 183 017: "TISPAN NGN; Gq' interface based on DIAMETER protocol". 

3GPP TR 23.981 (Release 6): "3rd Generation Partnership Project; Technical Specification Group 
Services and System Aspects; Interworking aspects and migration scenarios for IPv4 based IMS 
Implementations (Release 6)". 



4 Modifications to the main body of 3GPP TS 23.228 

Replace the references in 3GPP TS 23.228 [1] as shown in the table below. 





Reference in 3GPP TS 23.228 [1] 


Applicability to the present document 


1 


3GPP TS 23.002: "Network Architecture". 


ETSI ES 282 001 : "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); NGN Functional Architecture 
Release 1". (note 1) 


5 


GSM 03.64: "Digital cellular telecommunication system 
(Phase 2+); Overall Description of the General Packet Radio 
Service (GPRS) Radio Interface; Stage 2". 


(note 2) 


6 


GSM 01.04: "Digital cellular telecommunications system 
(Phase 2+); Abbreviations and acronyms". 


(note 2) 


7 


3GPP TS 23.221 : "Architectural Requirements". 


(note 2) 


8 


3GPP TS 22.228: "Service requirements for the IP multimedia 
core network subsystem". 


ETSI TS 181 005 "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Service and Capability 
Requirements" (note 1) 


9 


3GPP TS 23.207: "End-to-end QoS concept and 
architecture". 


(note 2) 


10 


3GPP TS 24.228: "Signalling flows for the IP multimedia call 
control based on SIP and SDP". 


(note 2) 


10a 


3GPP TS 24.229: "IP Multimedia Call Control based on SIP 
and SDP; Stage 3". 


ETSI ES 283 003: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); Endorsement of "IP 
Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description 
Protocol (SDP) Stage 3 (Release 6)" for NGN 
Release 1". (note 1) 


11 


3GPP TS 25.301 : "Radio interface protocol architecture". 


(note 2) 


19 


3GPP TS 33.203: "Access Security for IP-based services". 


(note 2) 


21 


3GPP TS 26.235: "Packet Switched Multimedia Applications; 
Default Codecs". 


ETSI TS 181 005 "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Service and Capability 
Requirements" (note 1) 


23 


3GPP TS 23.060: "General Packet Radio Service (GPRS); 
Service description; Stage 2". 


(note 2) 


24 


3GPP TS 23.003: "Technical Specification Group Core 
Network; Numbering, addressing and identification". 


(note 2) 


25 


3GPP TS 32.240: "Telecommunication management; 
Charging management; Charging architecture and principles". 


ETSI ES 282 010: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Charging (Endorsement of 
3GPP TS 32.240 v6.3.0, 3GPP TS 32.260 v6.3.0, 
3GPP TS 32.297 v6.1 .0, 3GPP TS 32.298 v6.1 .0 and 
3GPP TS 32.299 v6.4.0 modified)", (note 1) 
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Reference in 3GPP TS 23.228 [1] 


Applicability to the present document 


26 


3GPP TS 32.260: "Telecommunication Management; 
Charging Management; IP Multimedia Subsystem (IMS) 
charging". 


ETSI ES 282 010: "Telecommunications and Internet 
Converged Services and Protocols for Advanced 
Networking (TISPAN); Charging (Endorsement of 
3GPP TS 32.240 v6.3.0, 3GPP TS 32.260 v6.3.0, 
3GPP TS 32.297 v6.1 .0, 3GPP TS 32.298 v6.1 .0 and 
3GPP TS 32.299 v6.4.0 modified)", (note 1) 


27 


3GPP TS 22.071 : "Technical Specification Group Services 
and System Aspects, Location Services (LCS); Service 
description, Stage 1". 


(note 2) 


28 


3GPP TS 23.271 : "Technical Specification Group Services 
and System Aspects, Functional stage 2 description of LCS". 


(note 2) 


29 


3GPP TS 23.078: "Customised Applications for Mobile 
network Enhanced Logic (CAMEL) Phase 3 - Stage 2". 


(note 2) 


29a 


3GPP TS 22.340: "IMS Messaging; Stage 1". 


(note 2) 


30 


3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx 
Interfaces; Signalling flows and message contents". 


ETSI TS 183 033: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); IP Multimedia: IP Multimedia 
Subsystem (IMS) Cx and Dx Interfaces; Signalling 
flows and message contents & IP Multimedia (IM) 
Subsystem Cx and Dx Interfaces; Cx and Dx 
interfaces based on the Diameter protocol [3GPP 
TS.29.228 v.6.8.0 and 3GPP TS.29.229 v.6.6.0, 
modified]", (note 1) 


31 


3GPP TS 23.240: "3GPP Generic User Profile - Architecture; 
Stage 2". 


(note 2) 


32 


3GPP TS 22.250: "IP Multimedia Subsystem (IMS) group 
management; Stage 1". 


(note 2) 


36 


3GPP TS 23.141 : "Technical Specification Group Services 
and System Aspects, Presence Service". 


ETSI TS 182 008: "Telecommunications and Internet 
converged Services and Protocols for Advanced 
Networking (TISPAN); Presence Service; Architecture 
and functional description (Endorsement of 3GPP 
TS 23.141 and OMA-AD-Presence SIMPLE-V1 0)". 
(note 1) 


37 


3GPP TS 26.141 :"IMS messaging and Presence; Media 
formats and codecs". 


(note 2) 


NOTE 1 : The reference in 3GPP TS 23.228 [1] is replaced by the document listed on the right column. This 
replacement is applicable to all occurrences of the reference throughout the present endorsement. 

NOTE 2: The reference in 3GPP TS 23.228 [1] contains 3GPP specific requirements and is not generally applicable to 
the present endorsement. 



3.1 Definitions 

Add the following definition: 

Network Address Translation (NA(P)T): method by which IP addresses are mapped from one group to another, 
transparently to end users. Network Address Port Translation, or NA(P)T is a method by which many network 
addresses and their TCP/UDP (Transmission Control Protocol/User Datagram Protocol) ports are translated into a 
single network address and its TCP/UDP ports. See RFC 3022 [96] for further details. 

Replace the definition of " ALG" as follows: 

Application Level Gateway (ALG): application specific functional entity that allows communication between 
disparate address realm or IP versions when certain applications carry network addresses in the payloads like SIP/SDP. 
NA(P)T-PT or NA(P)T is application unaware whereas ALGs are application specific translation entities that allow a 
host running an application to communicate transparently with another host running the same application but in a 
different IP version or IP address realm. 

For IMS, an IMS ALG provides the necessary application function for SIP/SDP protocols in order to communicate 
between different address realms or IP versions. 

3.2 Symbols 

Add the following symbols or notes to the symbols in 3 GPP TS 23.228 [1] as shown below: 
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Gq' Reference Point between an IBCF and the SPDF 

3.3 Abbreviations 

Modify the following abbreviation: 

HSS Home Subscriber Server (Not relevant in NGN Release 1) 

Add the following abbreviations: 

IN Intelligent Network 

NAPT Network Address Port Translation 

NAT Network Address Translation 

NASS Network Attachment Subsystem 

RACS Resource and Admission Control Subsystem 

SPDF Service Policy Decision Function 

UPSF User Profile Server Function 

NP Number portability 

4.0 General 
Modify as shown below: 

- figure 4.0 is not endorsed 

4.1 Relationship to CS domain and the IP-Connectivity Access Network 

Modify the following sentence: 

The-IP-CANs^ that maintains the service while the terminal moves ,-an4 hides these moves from the IP multimedia 
subsystem. 

4.2.1.1 Support for CAMEL 

Modify the title and the text as follows: 

- replace "CAMEL" with "CAMEL or IN" 

- replace "CSE" with "CSE or IN Service Environment" 

4.6.1 Proxy-CSCF 

Add the following above the paragraph starting The functions peformed by the P-CSCF' 

The Service Policy Decision Function (SPDF) may be a logical entity of the P-CSCF or a separate physical node. If the 
SPDF is implemented in a separate physical node, the interface between the SPDF and the P-CSCF is the Gq' interface 
standardised in TS 183 017 [981 

Modify as shown below 

- If required for certain users, m Maintain a Security Association between itself and each UE, as defined in 
TS 33.203 [19]. 

- Should p Performs SIP message compression/decompression depending on the resources provided by the access 
technology in use and local policy . 

- Authorisation of bearer resources and QoS management. For details see TS 23.203 [54] and ES 282 003 [97] . 
NOTE: TS 23.203 [54] is not applicable when RACS is used. 

Add the following clause. 
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4. 1 8 Support of Number portability 



NOTE: The text of clause 4. 1 8. is except for this note identical to the text of clause 4. 1 8 of TS 23.228 version 
8.2.0 

4.18.1 Number portability 

Number portability (NP) allows a user to retain their E.164 number when changing subscriptions from one network 
operator to another. As such, NP applies to TEL URIs and SIP URI with user=phone parameters. NP is subject to 
regional requirements and is accomplished through the retrieval of ported data from those data bases. The specification 
of these data bases is out of scope of this document, but the NP data may be accessed through ENUM/DNS or accessed 
via existing (PSTN- and CS-domain) NP databases using the legacy PSTN/CS-domain protocols, such as TCAP. 

Support of NP within a network and the exact means to make the number portability data available to IMS, is subject to 
and configured per operator policy. NP is not mandated by this specification on any network operator. 

As configured per operator policy, IMS ENUM interfaces can be updated to support handling of the PSTN ENUM 
service per RFC 4769 [57], which provides a URI containing an E.164 number with NP routing information and NP dip 
indicators. The IMS entity receiving NP information as a result of an ENUM/DNS query, the S-CSCF as an example, 
needs to support, or not remove, NP protocol parameters retrieved as part of ENUM/DNS procedures contained in this 
specification. Subsequent network elements used to process the call to the PSTN do not remove the NP protocol 
parameters inserted in SIP messaging as part of the NP data retrieval procedure. 

NP data can also be made available by means of direct access to PSTN/CS-domain NP Databases using the legacy 
PSTN/CS-Domain interfaces and protocols. To support this existing interface within the network, the requesting and 
subsequent network elements need to support, or not remove, NP protocol parameters within SIP messages that result 
from the NP data retrieval procedures. The procedures to retrieve the NP data using the legacy PSTN/CS-domain 
interfaces are out of scope of this specification. 

Alternatively, per operator policy, the BGCF can retrieve NP data as part of the procedures to select an MGCF for 
PSTN connection. The interface used at the BGCF to retrieve the NP data is out of scope of this specification. 

Alternatively, per operator policy, the MGCF may support legacy interfaces to retrieve number portability data. 

NOTE: Although legacy protocols are used to access the number portability database, this does not imply that the 
IMS nodes (CSCFs, BGCFs) need to implement such protocols. 

5.0 General 

Modify the text as follows: 

This section documents the main procedures that are used for the provision of services in the IP multimedia subsystem. 
These procedures are described using text description as well as information flow diagrams. The procedures described 
in this document are meant to provide a high level description and are not intended to be exhaustive. Additional 
procedures and details are provided in TS 2 4 .228 [10] . 

5.2.2.5 Stored information 

Modify the text as follows: 

Table 5.1 provides an indication of some of the information stored in the indicated nodes during and after the 
registration process. Note that Table 5.1 is not an exhaustive list of stored information, i.e. there can be additional 
information stored due to registration. 
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Table 5.1 : Information Storage before, during and after the registration process 



Node 


Before Registration 


During Registration 


After Registration 


UE - in local network 


Credentials 
Home Domain 
Proxy Name/Address 


Same as before 
registration 


Credentials 
Home Domain 
Proxy Name/Address 
UE P-GRUU 
At least one T-GRUU 


Proxy-CSCF 

- in Home or Visited 

network 


Routing Function 


Initial Network Entry point 

UE Address 

Public and Private User 

IDs 

And if the P-CSCF is 

located in a visited 

network: 

- IBCF in the visited 

network address/name 


Final Network Entry point 

UE Address 

Public and Private User 

IDs 

And if the P-CSCF is 

located in a visited 

network: 

- IBCF in the visited 

network address/name 


Interrogating-CSCF - in 
Home network 


HSS or SLF Address 


Serving-CSCF 
address/name 
P-CSCF Network ID 
Home Network contact 
Information 


No State Information 


HSS 


User Service Profile 


P-CSCF Network ID 


Serving-CSCF 
address/name\ 


Serving-CSCF (Home) 


No state information 


HSS Address/name 
User profile (limited - as 
per network scenario) 
Proxy address/name 
P-CSCF Network ID 
Public/Private User ID 
UE IP Address 
UE P-GRUU 
UET-GRUU 


May have session state 
Information 
Same as during 
registration 



5.4 



Procedures for IP Multi-media sessions 



5.4.2a IP version interworking concepts 

Modify as shown below 

It should be possible for users connected to an IMS network to communicate with users that are 

connected to SIP based networks that use a different IP version via interworking or that are in a 

separate addressing range (e.g., NA(P)T functionality is set at the border of the IMS) . 

5.4.4 Requirements for IP multi-media session control 

Modify as shown below: 

6. The solution shall comply with the architectural rules relating to separation of bearer level, session control level, 
and service level expressed in 23.221 [7] . 

5.4.5 Session Path Information 
Modify the text as follows: 

5.4.5.1 Session Path Information during Registration and Session Initiation 

During registration and session initiation there are SIP mechanisms, which provide the means to determine the session 
path. 

After registration the P-CSCF stores the S-CSCF name , possibly IBCF names and the S-CSCF stores the P-CSCF name 
and possibly IBCF names (see 4.3.4) as part of the UE related information. 
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There is a need to store the session path that is determined during the session initiation request in order to route the 
subsequent session requests through this determined path. This is needed in order to route these session requests 
through certain nodes, e.g. the ones performing Service Control , or interconnect functions . CSCFs are assumed to 
perform certain actions: 

1. CSCFs (Proxy and Serving) store a certain part of the session path determined during session initiation. This 
allows CSCFs to generate requests that traverse all elements on a Route path. 

2. The P-CSCF shall check correct usage of the header values. Should an UE build inaccurate header(s) in a SIP 
request, the P-CSCF may reject the request. If an operator policy requires enforcing the routes stored in P-CSCF, 
the P-CSCF shall overwrite the header(s) provided by the UE with the appropriate values. 

5.4.7 Interaction between QoS and session signalling 

Clauses 5.4.7.0 to 5.4.7.7 are not applicable to IP-CANs using RACS. 

Add the following clause: 

5.4.7a Interaction between RACS and IMS 

The P-CSCF interacts with the RACS in order to do the following: 

- Request bindings data between the different IP addresses (NA(P)T or NA(P)T-PT) upon session 
initiation/modification. 

- Request media latching in hosted NAT scenarios. 

- Release the bindings at session release. 

- Open/close gates between domains (i.e. packets filtering depending on "IP address / port"). 
Perform packet marking. 

- Resource allocation and bandwidth reservation for upstream and downstream traffic. 
Policing of incoming traffic. 

More details can be found in ES 282 003 [97] and TS 183 017 [98]. 

5.6 Origination procedures 

Modify the text as follows: 

5.6.1 (MO#1) Mobile origination, roaming 

This clause is endorsed with the clarification that "P-CSCF(PCRF)" is replaced with "P-CSCF". 

5.6.2 (MO#2) Mobile origination, home 

This clause is endorsed with the clarification that "P-CSCF(PCRF)" is replaced with "P-CSCF". 
Insert the following clause: 

5.6.2a (FO#1) Fixed origination, home 

This origination procedure applies to users located in their home service area. As in clause 5.6.2, the UE is located in 
the home network, but is using an xDSL IP-CAN to access the IMS Core. 

NOTE: The below flows are example flows. The detailed stage 2 description of the RACS information flows can 
be found in ES 282 003 [97]. 
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Originating Home Network 



UE 



C-BGF 



1. INVITE (SDP offer) 



9. Offer Response 



10. Resp. Conf(OptSDP) 



15.Conf Ack 



18. Ringing 



Ringing 



RACS P-CSCF 



2. Reserve Connection 



8. Resource Admission & 
Connection Configuration 



21. Approval of QoS Commit 
&.Open Gates 



3. INVITE (SDP offer) 



7. Offer Response 



11. Resp. Conf (Opt SDP) 



17. Ringing 



S-CSCF 



4. Service Control 



5. INVITE (SDP offer) 



6. Offer Response 



12. Resp. Conf (Opt SDP) 



13. Conf Ack 



16. Ringing 



Figure 5.15a: Fixed xDSL originating - home (example flow) 

Procedure F0#1 is as follows: 

1. UE sends the SIP INVITE request, containing an initial SDP, to the P-CSCF address determined with P-CSCF 
discovery mechanism. The initial SDP may represent one or more media for a multi-media session. 

2. A connection is reserved in the C-BGF with optional NAT binding list retrieval. 

3. P-CSCF remembers (from the registration procedure) the next hop CSCF for this UE. In this case it forwards the 
INVITE to the S-CSCF in the home network. 

4. S-CSCF validates the service profile, and invokes any origination service logic required for this user. This 
includes authorisation of the requested SDP based on the user's subscription for multi-media services. 

5. S-CSCF forwards the request, as specified by the S-S procedures. 

6. The media stream capabilities of the destination are returned along the signalling path, per the S-S procedures. 

7-9. S-CSCF forwards the Offer Response message to the P-CSCF which triggers RACS. RACS performs 
admission control based on the Offer and Answer parameters. 

RACS configures the connections in the C-BGF based on the SDP answer and optionally requests a NAT 
binding list. 

10. UE decides the offered set of media streams for this session, confirms receipt of the Offer Response and sends 
the Response Confirmation to P-CSCF. The Response Confirmation may also contain SDP. This may be the 
same SDP as in the Offer Response received in Step 9 or a subset. If new media are defined by this SDP, a new 
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connection configuration shall be performed following Step 2. The originating UE is free to continue to offer 
new media in this request or in subsequent requests using the Update method. Each offer/answer exchange will 
cause the P-CSCF to repeat the RACS interactions again. 

1 1. P-CSCF forwards this message to S-CSCF 

12. S-CSCF forwards this message to the terminating endpoint, as per the S-S procedure. 

13. The terminating end point responds to the originating end with an acknowledgement. If Optional SDP is 
contained in the Response Confirmation, the Confirmation Acknowledge will also contain an SDP response. If 
the SDP has changed, the admission control and configure connection flows are repeated. 

14-15. S-CSCF and P-CSCF forward the answered media towards the UE. 

16-18. The destination UE may optionally perform alerting. If so, it signals this to the originating party by a 

provisional response indicating Ringing. This message is sent to S-CSCF per the S-S procedure. It is sent from 
there toward the originating end along the signalling path. UE indicates to the originating user that the 
destination is ringing. 

19-20. When the destination party answers, the terminating endpoint sends a SIP 200-OK final response along the 
signalling path to the originating endpoint, as specified by the termination procedures and the S-S procedures. 

21. P-CSCF performs the approval of QoS Commit procedure which triggers the Open Gates procedures if required. 

22. P-CSCF passes the 200-OK response back to UE 

23. UE starts the media flow(s) for this session. 

24-26. UE responds to the 200 OK with an ACK message which is sent to P-CSCF and passed along the signalling 
path to the terminating endpoint. 

Insert the following clause: 

5.7.2b (FT#1) Fixed termination, home 

NOTE: The below flows are example flows. The detailed stage 2 description of the RACS information flows can 
be found in ES 282 003 [97]. 

This termination procedure applies to users located in their home service area. As in clause 5.7.2, the UE is located in 
the home network, but has registered to the IMS Core via an xDSL IP-CAN. 
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Figure 5.18b: Fixed xDSL terminating - home (example flow) 

Procedure FT#1 is as follows: 

1. UE#1 sends the SIP INVITE request, containing an initial SDP, via one of the origination procedures and the S- 
S procedures, to the Serving-CSCF for the terminating UE. 

2. S-CSCF validates the service profile, and invokes any termination service logic required. This includes 
authorisation of the requested SDP based on the user's subscription for multi-media services. 

3. S-CSCF remembers (from the registration procedure) the P-CSCF address for this UE. The S-CSCF forwards the 
INVITE to the P-CSCF, which in this case is located in the home network. 

4. The P-CSCF triggers RACS which reserves a connection in C-BGF with optional NAT binding retrieval. 

5. P-CSCF remembers (from the registration procedure) the UE address, and forwards the INVITE to the UE. 

6. UE determines the subset of the media flows proposed by the originating endpoint that it is capable and willing 
to support, and responds with an Offer Response message back to the originator. The SDP may represent one or 
more media for a multi-media session. This response is sent to the P-CSCF. 

7. P-CSCF triggers RACS to perform admission control based on Offer and Answer parameters. 

RACS configures the connection in the C-BGF based on SDP answer with optional NAT binding retrieval. 

8. P-CSCF forwards the Offer Response message to S-CSCF. 

9. S-CSCF forwards the Offer Response message to the originator, per the S-S procedure. 
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10-15. The originating endpoint sends a Response Confirmation via the S-S procedure, to the terminating S-CSCF. 
The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response sent in 
Step 19 or a subset. If new media are defined by this SDP, a new interaction with the RACS (as in Step 4-8) will 
be done by the P-CSCF. The originating UE is free to continue to offer new media in this request or in a 
subsequent request using the Update method. Each offer/answer exchange will cause the P-CSCF to repeat the 
RACS interactions (Step 4-8) again. 

16-18. UE may alert the user and wait for an indication from the user before completing the session. If so, it 
indicates this to the originating party by a provisional response indicating Ringing. This message is sent to 
P-CSCF and along the signalling path to the originating endpoint. 

19. When the destination party answers, UE sends a SIP 200-OK final response to P-CSCF. 

20. P-CSCF indicates that the resources reserved for this session should now be committed. 

21-22. P-CSCF forwards the 200-OK to S-CSCF, following the signalling path. 

23-25. The session originator responds to the 200-OK by sending the ACK message to S-CSCF via the S-S 
procedure and it is forwarded to the terminating end along the signalling path. 

Annex G (Normative): Reference Architecture and procedures when the NAT is invoked between the UE and 
the IMS domain 

Modify as follows: 

G.2 Reference model 

The requirements in this clause do not apply when RACS is used. 

Add the following clause: 



G.2A 



Reference model with RACS 



Figure G.la presents the general reference model for IMS access when both the signalling and media traverses NAT 
devices. Figure G.2a presents the general reference model when IP address translation is needed between the IP-CAN 
and the IMS domain. The IMS network architecture is the same for both cases. 

NOTE: The P-CSCF and the C-BGF may belong to different operators. 
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Figure G.1a: Reference model for IMS access where UE is located behind a hosted NAT 
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Figure G.2a: Reference model for IMS access with IP address conversion in the media path 

Network elements for employing the IMS-ALG and IMS Access Gateway 



G.3.1 Required functions of the P-CSCF 

The requirements in this clause do not apply when RACS is used. 
Add the following clause: 



G.3.1A 



Required functions of the P-CSCF with RACS 



For performing communication with UEs when IP address translation is needed between the IP-CAN and the IMS 
domain on the media path only (Figure G.2a) or on both the media and signalling (Figure G.la), the P-CSCF shall 
perform the following functions: 

- Act as an IMS-ALG by changing the appropriate SIP/SDP parameters in order to translate addresses into same or 
different IP version addresses, in case NA(P)T or NA(P)T-(PT) is required between the IP-CAN domain and the 
IM Subsystem core network elements. 

- Request the RACS to provide the IP address bindings data upon session initiation, to modify those bindings any 
time during the session, and to release the bindings at session release. 

Additionally in support of the hosted NAT scenarios (see Figure G.l), the P-CSCF shall request the RACS to initiate 
media latching, in order to retrieve the remote address information of the media received from, and sent to, a NAT 
device between the P-CSCF and the served UE. 

G.3. 2 Required functions of the IMS Access Gateway 

The requirements in this clause do not apply when RACS is used. 

G.3. 3 Iq reference point 

The requirements in this clause do not apply when RACS is used. 

Add the following clause: 

G.4.2a NAT traversal for signalling 

To keep the NAT binding and firewall pinholes open for signalling traffic, one of the following methods shall apply: 

• A registration timer shall be provisioned in the P-CSCF for the TEs behind a NAT or firewall. To minimize the 
number of SIP Register messages between the P-CSCF and the S-CSCF, the P-CSCF may forward the 
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minimum number of SIP Register messages required by the S-CSCF registration timer. This method is 
controlled by the P-CSCF, and has the benefit to be transparent to the TE 

• An Outbound [48] keep alive for NAT binding may be sent by the TE to the SIP port of the P-CSCF using the 
same transport address information (source and destination) which was used for the registration request. This 
method is controlled by the TE. It may be complementary to the first one in case the P-CSCF does not 
provision the appropriate registration timer for the TE. 

G.4.3 Session establishment procedure 

The requirements in this clause do not apply when RACS is used. 

G.4.4 Session release procedure 

The requirements in this clause do not apply when RACS is used. 

G.4.5 Session modification 

The requirements in this clause do not apply when RACS is used. 

G.4.6 Media forwarding in the IMS Access Gateway 

The requirements in this clause do not apply when RACS is used. 

G.5 Network elements for employing NAT Traversal for ICE and Outbound 

The requirements in this clause do not apply when RACS is used. 

G.6 Procedures for employing ICE and Outbound 

The requirements in this clause do not apply when RACS is used. 

Annex I (normative): Border Control Functions 

Modify as follows: 

Replace clause 1.2 by the following: 

1.2 Overall architecture 

Figure 1.2.1 presents a high-level architecture diagram showing how Border Control Functions fit into the IMS 
architecture. 
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Figure 1.1: Border Control Functions 

The Mx reference point allows S-CSCF/I-CSCF/P-CSCF to communicate with an IBCF in order to provide border 
control functions. 

1.3.1 .1 Originating Session Flows towards IPv4 SIP network 

This clause is endorsed with the clarification that the TrGW is replaced by the I-BGF when the RACS is used. 

1.3.1 .2 Terminating Session Flows from IPv4 SIP network 

This clause is endorsed with the clarification that the TrGW is replaced by the I-BGF when the RACS is used. 
Add the following clause: 



I.3.2A 



Additional IBCF screening functions 



The IBCF can filter all SIP signalling information based on source/destination and operator policy (e.g. remove 
information that is of local significance to an operator). 



Add the following clause: 



I.3.2B 



Addition of the IWF 



The IBCF can detect whether an IWF needs to be added in the SIP signalling path. The IBCF can insert the IWF in the 
signalling route when appropriate. 
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Add the following annex: 



Annex ZA (normative): 
IP version considerations 



The present document does not place any requirement with regards to the IP version to be supported by UEs for 
accessing the IMS Core. More specifically the following scenarios are supported: 

IP version 4 only UEs accessing the IMS Core. 

- IP version 6 only UEs accessing the IMS Core. 

- Dual stack UEs accessing the IMS Core. 

The IP version used by IMS Core entities (e.g. CSCFs) to exchange SIP signalling depends on the IP version used by 
the terminals that a given operator is willing to support. A number of scenarios are hence possible. 

NOTE: An analysis of the requirements deriving for each of those scenarios in a GPRS environment can be found 
in 3GPPTR 23.981 [99]. 
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Annex ZB (normative): 
Interaction with the RACS 

ZB.1 IBCF interaction with the RACS 

The IBCF may interact with the RACS in order to do the following: 

- Provide the RACS with information on the "resource reservation service class" required for a particular session; 
the "resource reservation service class" enables the RACS to derive transport layer characteristics required for a 
session (e.g. decision to include an I-BGF for the session, or media interconnect link selection. . .). 

- Request bindings data between the different IP addresses (NA(P)T or NA(P)T-PT) upon session 
initiation/modification. 

- Release the bindings at session release. 

- Open/close gates between domains (i.e. packets filtering depending on "IP address / port"). 
Perform packet marking. 

- Resource allocation and bandwidth reservation for upstream and downstream traffic. 

- Policing of incoming traffic. 

The above functions may or may not instantiated by the IBCF depending on local policy and incoming signalling 
information. Additionally, the IBCF may decide, in some cases, based on the SIP signalling and operator- specific 
policy, not to contact the RACS. 
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